パフォーマンス最適化

• コントローラーのプロセッサ コアには共有キャッシュを使用しないでください。

• ターゲットデバイスにイーサネットベースのフィールドバスを使用している場合は、それらに物理アダプタを使用してください。スイッチ アーキテクチャは使用しないでください。

• リアルタイム カーネルを使用します。

  RT プリエンプト カーネルの使用をお勧めします (https://rt.wiki.kernel.org) Linux システム用。 Debian および Ubuntu ディストリビューションの場合、RT カーネルはパッケージとして提供されており、次のコマンドを使用して簡単にインストールできます。 apt 指示。詳細については、ディストリビューションのマニュアルを参照してください。

  • Debian システムの場合

    sudo apt-get install linux-image-rt-amd64

  • 使用しているカーネルを確認してください uname -a 指示。例えば。

• システム上でウィンドウ マネージャー、GUI/X サーバー、または類似のものを使用することは避けてください。

  これらのツールを使用すると、システムのリアルタイム機能に影響を及ぼし、IEC アプリケーションで高いジッターが発生する可能性があります。

「rt-tools」の使用:

• 「rt-tools」のインストール: sudo apt install rt-tests

• 「cyclictest」を開始します。 sudo cyclictest -p 99 -t -m

• の man cyclictest コマンドでは、システムのより詳細な、または特定のパフォーマンス側面をより適切に測定するために使用できる、より多くのコマンド ライン オプションが表示されます。

• CPU の省エネモードを無効にします。

• ハイパースレッディングを無効にします。

  次のコマンドを使用してハイパースレッディングを無効にできます (例)。

  echo off | sudo tee /sys/devices/system/cpu/smt/control

• CPU 周波数のスケーリングと切り替えを可能な限り無効にします。

  たとえば、CPU 周波数の最小値と最大値を同じ (固定) 値に設定します。

• Linux カーネルのリアルタイムスロットリングメカニズムを無効にしてください。これにより、システムにジッターが発生する可能性があります。

  詳細については、以下を参照してください。 Linux の基礎:スケジューリング — RT スロットリング

  次のコマンドを使用してリアルタイムスロットリングを無効にできます (例)。

  echo -1 > /proc/sys/kernel/sched_rt_runtime_us

• スケジューリング/スケーリングガバナーを確認および変更します。

  • 使用されているスケジューリング/スケーリング ガバナーを確認します。

    cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

  • 使用するスケジューリング/スケーリングガバナーを変更します( root/admin） に Performance:

    echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
    # set it for all available cores:
    echo "performance" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
    echo "performance" > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
    echo "performance" > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor

    システムを起動するたびにスケーリング ガバナをリセットする必要があることに注意してください。カーネル構成を使用して設定することもできます。

    の intel_pstate カーネルドライバーにより、正しい設定がより困難になる場合があります。したがって、次を使用する必要があります。 cpufreq-info コマンドを使用して構成を確認します。

  • 次のようなプログラムも使用できます。 cpu-freq-utils。これにより、Intel psstate ドライバーが妨害される可能性があります。これらのドライバーは通常、CPU 周波数を設定するために別のアプローチを必要とします。

  • 詳細については、以下を参照してください。 https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt

• 無効にする HyperV BIOS 内 (利用可能な場合)。

• システムを最適化するアプリケーションを大まかに説明するテスト アプリケーションを作成します (必要なリソース、必要なパフォーマンス、プロジェクト サイズの観点から)。

• これを繰り返し行うことができます。最初に非常に大まかな近似を作成し、それを拡張して実際のアプリケーションにどんどん近づけます。

• 分。ジッタ (μs) / 最大ジッター (μs)

  • 値は、「cycletest」プログラムによって決定された値にできるだけ近い必要があります。詳細はセクションで説明されています Linuxのセットアップ。

  • ジッターと遅延の詳細については、以下を参照してください。 ジッターとレイテンシーの定義

  • [監視] タブの詳細については、次を参照してください。 タブ: モニタリング

• 平均サイクル時間 (μs) / 最大サイクルタイム (μs) サイクルタイム (μs)

  • 最大サイクルは、設定されたサイクル タイムに決して近づいてはなりません。これにより、システムに高負荷がかかるとすぐに問題が発生します。

  • サイクルタイムは常にできるだけ短くしてください。

• 長時間実行されるタスクを複数の小さなタスクに分割します。

• 実行中、最も優先度の高いタスクの最大サイクル タイムは、設定されたサイクル タイムに決して達してはなりません。これを回避できない場合は、設定されたサイクル タイムを増やして、一貫した実行時間を確保する必要があります。

• フィールドバス システム (EtherCAT や PROFINET など) を開始する場合、開始サイクルにより CPU 負荷がわずかに高くなる可能性があります。この場合、アプリケーションの起動直後に CPU 負荷を監視することが合理的です。

次のオプションは変更できません CODESYS Virtual Control SLただし、ホスト上で構成する必要があります。

• の値を設定します DisableCpuDmaLatency 1に:

  [SysCpuHandling]
  Linux.DisableCpuDmaLatency=1

  • これはランタイム バージョン 4.11.0.0 のデフォルト設定であることに注意してください。

  • ランタイムのバージョンを確認するには、 エクストラ → Linuxをアップデートする → システム → システム情報。

• 本当にリアルタイムカーネルが使用されているか確認してください。

  • バージョン 4.11.0.0 では、PLC シェル コマンドを使用できます。 rt-get kernelinfo これを確認するために。

  • 古いバージョンをお使いの場合は、コマンドラインで次のコマンドを使用してこれを直接実行できます。 uname -a。

  • リアルタイム カーネルが使用されていない場合は、最初からやり直す必要があります。

• 前のステップのテストを使用できます CODESYS ランタイム システムの構成 IEC アプリケーションをテストします。

• 使用できます マルチコア の特徴 CODESYS。

• タスクの正しい優先順位を決定します。重要なタスクは優先順位を高くする必要があります。

  表 5. IEC タスクの優先順位と Linux スレッドの優先順位のマッピング:

  IEC タスクの優先順位	Linuxの優先順位
  --	88 (SCHED_FIFO)
  --	57 (SCHED_FIFO)
  0 (リアルタイム優先度が最も高い)	56 (SCHED_FIFO)
  15 (リアルタイム優先度が最も低い)	41 (SCHED_FIFO)
  16 (リアルタイム優先ではない)	0 (SCHED_OTHER)
  31 (リアルタイム優先ではない)	0 (SCHED_OTHER)
  --	0 (SCHED_OTHER)
  注記 従来の Linux システムでは、ほとんどの割り込み (IRQ) とカーネルワーカーは Linux の優先度が 50 です。それを上回る優先順位 (高負荷) を使用すると、システム機能 (ネットワーク/ストレージ) が期待どおりに動作しなくなる可能性があります

  
  
  

• タスクの優先度は、それぞれのタスク設定で設定できます。

  

ここで説明したすべての手順を実行しても望ましいパフォーマンスが得られない場合は、次のセクションを参照してください。

• フィールドバス固有の情報

• [専門家向け] – 追加のツールとトピック

• チェックしてください Send Time / Recv Time EtherCAT ステータス ページの値。

  • Intel Core i7 プロセッサを搭載した x64 CPU と適切なアダプタでは、10µs 未満になるはずです。

  • チップが統合された ARM プロセッサでは、最大 50µs 以上の時間がかかります。

  

• チェックしてください Send Time / Recv Time PROFINET ステータス ページの値。

  • Intel Core i7 プロセッサを搭載した x64 CPU と適切なアダプタでは、10µs 未満になるはずです。

  • チップが統合された ARM プロセッサでは、最大 50µs 以上の時間がかかります。

  

• 優先順位と必要な IRQ を並べ替えるには、PLC シェル コマンドを使用できます。 irq-list そして irq-set-prio。

  • これらのコマンドは、IEC 優先順位ではなく、通常の Linux 優先順位を使用します。

  • この最適化は次の場合には実行できません。 CODESYS Virtual Control SL、むしろホストシステム上で。

• デバイスには別のネットワーク アダプターを使用してください。

• 詳細については、以下を参照してください。

  • EtherCAT

  • プロフィネット

  • イーサネット/IP

  • CANbus、CANopen

• KernelShark / カーネル トレース

  • これは、パフォーマンスの問題の原因がスケジュールにあることが判明した場合に最適なプログラムです。 「カーネル トレース」を使用すると、タスクが別のタスク、別のサービス、または割り込みによって中断されているかどうかを確認できます。

    • trace-cmd record -p function

    • KernelShark を使用して、生成された trace.dat ファイル。

  • 一般に、スケジュールの問題は次の 2 つのカテゴリに分類できます。

    • スーパーセッション/プリエンプション

      • 実行を妨げる割り込みやタスクが不要な場合は、割り込みを禁止してください。

      • 自分のタスクの優先度を上げるか、他のタスクの優先度を下げます。

      • 別の CPU コアに切り替えます。

      重要

      前の章で説明したプログラムを使用して、変更の有効性を確認します。

    • 実行時間

      以下の「カーネル関数トレース」を参照してください。

• カーネル関数トレース

  • コードの実行時間が長すぎると判断した場合は、このツールを使用して問題を特定できます。

  • 実行時間が長すぎる関数が独自のコードにある場合は、それを最適化する必要があります。

  • 実行時間が長すぎる関数がカーネル内にある場合は、別のカーネル関数を使用して目的の機能の実現を試みることができます。あるいは、実行時間を短縮するために、カーネル ドライバーに構成パラメーターを渡すこともできます。

  • これらのオプションのいずれも問題を解決しない場合は、おそらく、より強力なハードウェアを使用する必要があります。

次の点に注目して、それらがパフォーマンス目標を達成するための正しいツールであるかどうかを確認してください。

• PREEMPT_FULL

• isolcpu

• rcu_nocbs

• rcu_nocb_poll

• ソフトロックアップなし

• irqbalance の無効化

• kernel.sched_rt_runtime_us